When developing hardware- and also software-implemented systems, the compatibility of components, particularly their reusability, must be ensured where possible. To this end, software systems can be built in a modular design based on reusable software components, such as program modules, libraries or packages. Computer systems can be of modular design comprising hardware components, the compatibility of which is provided by standardized interfaces. For example, a plurality of software components are designed to be executable not only on individual computer systems but also on different computer systems without significant overhead. The reusability of software components, particularly on different computer systems, makes for an optimized cost-benefit ratio. Reusability is a motivating factor for the writing of high-quality software code that is sufficiently tested and well documented. Another advantageous aspect is the possibility of buying-in high-quality software code from external developers.
The approach of not having to design software components for a specific target system has gained acceptance with the widespread use of the higher-level programming languages. Software components are created which are translated by translators or more specifically compilers from the high-level language into the machine language of the respective target system. Prior to this, software components were implemented directly in the machine language for the target system in question. Since machine languages are less intuitively understandable to humans compared to high-level languages, this procedure involved more time and effort and was more prone to error. In particular, the software code could not be reused in most cases. Constantly implementing new software components likewise resulted in increased error proneness. For reasons of cost-effectiveness and reusability, software components should not be geared precisely to a target system and its precise technical details. An abstraction is consciously assumed in order to develop a software component more quickly, more efficiently and with fewer errors.
The compatibility of hardware components is a nonfunctional requirement which is desirable and necessary. On the other hand, technological progress means that there is a great diversity of hardware. Thus, different controllers with specific performance data can be used, for example. Similarly there are different storage media which differ considerably from one another in terms of price and performance. Hardware units usually have standard interfaces which are completely identical functionally. Due in particular to specific design and architecture patterns such as layering or proxies, a software engineer does not usually know which precise version of a hardware unit the software component will be accessing.
The above-mentioned aspects show that complete test coverage of a software component in respect of the hardware components used is only possible by investing a significant amount of time and effort. For example, hardware components on which the software component is to be implemented may be compatible in terms of the hardware-based interfaces, but the performance characteristics of the hardware components cannot satisfy the requirement parameters of the software component. In a particularly disadvantageous case this may result in an unserviceable software product in respect of the hardware components used. In this context a software product comprises at least one software component.
For example, in the case of software products, requirement parameters for the executing hardware components are specified which ensure a well-defined program flow. The program flow in this context encompasses the execution of a software component. Requirement parameters are determined, for example, by testing the software product on different physical computer systems. However, due to the increasing diversity of the computer systems, these requirement parameters can no longer be determined empirically, or only to an inadequate extent. In particular, dependencies between the operating parameters of the hardware units used can only be determined with enormous empirical overhead. If corresponding requirement parameters are available in full and are sufficiently precise, it is possible to make assessments concerning the operating parameters of the required hardware components. In particular, in terms of using the corresponding hardware units, costs can be saved by replacing a higher-performance but more expensive hardware unit by a cheaper hardware unit. The use of overly high-performance hardware units results in increased additional operating costs, in particular higher energy consumption or more specifically higher heat emission which has to be compensated by more intensive use of cooling components.
Due to the large range of functionally compatible hardware units, conventional techniques for determining requirement parameters can only test selected operating parameter profiles. Complete testing of all the operating parameter profiles for existing hardware components is virtually impossible due to the great multiplicity of possible combinations of hardware components for implementing a suitable computer system. Usually, precise requirements for the hardware components are only determined in a rudimentary and unsystematic fashion. Testing is therefore frequently not performed using a sufficient range of hardware components, but only on a small number of exemplary computer systems.
The use of mathematical models such as Markov chains or weighted Petri nets, for example, for determining requirement parameters necessitates the costly involvement of experts, can be susceptible to error and/or imprecise, which may prove to be particularly disadvantageous.